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Abstract 

We describe a new, dynamic, floating-label approach to language- 
based information flow control, and present an implementation in 
Haskell. A labeled 10 monad, LIO, keeps track of a current label 
and permits restricted access to IO functionality, while ensuring 
that the current label exceeds the labels of all data observed and 
restricts what can be modified. Unlike other language-based work, 
LIO also bounds the current label with a current clearance that pro¬ 
vides a form of discretionary access control. In addition, programs 
may encapsulate and pass around the results of computations with 
different labels. We give precise semantics and prove confidential¬ 
ity and integrity properties of the system. 

Categories and Subject Descriptors D.1.1 [ Programming Tech¬ 
niques ]: Applicative (Functional) Programming; D.3.3 [ Program¬ 
ming Languages ]: Language Constructs and Features—Modules, 
packages 

General Terms Security, Languages, Design 
Keywords Information flow control. Monad, Library 

1. Introduction 

Complex software systems are often composed of modules with 
different provenance, trustworthiness, and functional requirements. 
A central security design principle is the principle of least privilege, 
which says that each component should be given only the privileges 
it needs for its intended purpose. In particular, it is important to dif¬ 
ferentially regulate access to sensitive data in each section of code. 
This minimizes the trusted computing base for each overall func¬ 
tion of the system and limits the downside risk if any component is 
either maliciously designed or compromised. 

Information flow control (IFC) tracks the flow of sensitive data 
through a system and prohibits code from operating on data in vio¬ 
lation of security policy. Significant research, development, and ex¬ 
perimental effort has been devoted to static information flow mech¬ 
anisms. Static analysis has a number of benefits, including reduced 
run-time overhead, fewer run-time failures, and robustness against 
implicit flows [10]. However, static analysis does not work well in 
environments where new classes of users and new kinds of data 
are encountered at run-time. In order to address the needs of such 
systems, we describe a new, dynamic, floating-label approach to 
language-based information flow control and present an implemen¬ 
tation in Haskell. 
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Our approach uses a Labeled type constructor to protect values 
by associating them with labels. However, the labels themselves 
are typed values manipulated at run-time, and can thus be created 
dynamically based on other data such as a username. Conceptually, 
at each point in the computation, the evaluation context has a 
current label. We use a labeled IO monad, LIO, to keep track of 
the current label and permit restricted access to IO functionality 
(such as a labeled file system), while ensuring that the current 
label accurately represents an upper bound the labels of all data 
observed or modified. Unlike other language-based work, LIO also 
bounds the current label with a current clearance. The clearance of 
a region of code may be set in advance to impose an upper bound 
on the floating current label within that region. This restricts data 
access, limits the amount of code that could manipulate sensitive 
data, and reduces opportunities to exploit covert channels. Finally, 
we introduce an operator, toLabeled, that allows the result of a 
computation that would have raised the current label instead to be 
encapsulated within the Labeled type. 

The main features of our system can be understood using the ex¬ 
ample of an online conference review system, called AChair. In this 
system, which we describe more fully later in the paper, authenti¬ 
cated users can read any paper and can normally read any review. 
This reflects the normal practice in conference reviewing, for exam¬ 
ple, where every member of the program committee can see sub¬ 
missions, their reviews, and participate in related discussion. Users 
can be added dynamically and assigned to review specific papers. 
In addition, as an illustration of the power of the labeling system, 
integrity labels are used to make sure that only assigned reviewers 
can write reviews for any given paper. Conversely, confidentiality 
labels are used to manage conflicts of interest. Users with a conflict 
of interest on a specific paper lack the privileges, represented by 
confidentiality labels, to read a review. As conflicts of interest are 
identified, confidentiality labels on the papers may change dynam¬ 
ically and become more restrictive. It is also possible to remove 
conflicts of interest dynamically, if desired. A subtlety that we have 
found advantageous is that reviewers with a conflict of interest can 
potentially refer to reviews (by having a name that is bound to a re¬ 
view) but cannot perform specific operations simply because they 
can refer to them. As we have structured our online conference re¬ 
view system, the actual display of a conflict-of-interest review is a 
prohibited operation. 

The main contributions of this paper include: 

► We propose a new design point for IFC systems in which most 
values in lexical scope are protected by a single, mutable, cur¬ 
rent label, yet one can also encapsulate and pass around the re¬ 
sults of computations with different labels. Label encapsulation 
is explicitly reflected by types in a way that prevents implicit 

► We prove information flow and integrity properties of our de¬ 
sign and describe LIO, an implementation of the new model in 


Haskell. LIO, which can be implemented entirely as a library 
(based on type safety), demonstrating both the applicability and 
simplicity of the approach. 

► Unlike other language-based work, our model provides a no¬ 
tion of clearance that imposes an upper bound on the program 
label, thus providing a form of discretionary access control on 
portions of the code. 

IFC originated with military applications [5, 11] that label data 
and processes with sensitivity security levels. The associated label¬ 
checking algorithms then prevent a Trojan horse reading classified 
data, for example, from leaking the data into less classified files. In 
operating systems, IFC is generally enforced at the kernel bound¬ 
ary, allowing a small amount of trusted code to impose a flexible 
security policy on a much larger body of supporting software. Ex¬ 
tending the core concepts of IFC to a broader range of situations 
involving mutually distrustful parties that mix their code and data, 
Myers and Liskov [28] subsequently introduced a decentralized la¬ 
bel model (DLM) that has been the basis of much subsequent OS 
and language-based work. Unfortunately, despite its attractiveness, 
the DLM is not widely used to protect data in web applications, 
for example. In the operating systems domain, most of the past 
DLM-inspired work has relied exclusively on dynamic enforce¬ 
ment [21, 37, 39], This is due to the dynamic nature of operat¬ 
ing systems, which must support a changing set of users, evolving 
policies, and dynamically loaded code. But it is often inconvenient 
to establish security domains by arranging software according to 
course-grained kernel abstractions like processes and files. More¬ 
over, adopting a new OS presents an even bigger barrier to deploy¬ 
ment than adopting a new compiler. LIO uses the type system to 
enforce abstraction statically, but checks the values of labels dy¬ 
namically. Thanks to the flexibility of dynamic checking, the li¬ 
brary implements an IFC mechanism that is more permissive than 
previous static approaches [26, 30, 32] but providing similar secu¬ 
rity guarantees [34]. Though purely language-based, LIO explores 
a new design point centered on floating labels that draw on past OS 
work. Both the code and technical details omitted in this paper can 
be found at http://www.scs.Stanford.edu/~deian/lio. 

2. Security Library 

In this section, we give an overview of the information flow control 
approach used in our dynamic enforcement library for Haskell. 

2.1 Labels and IFC 

The goal of information flow control is to track and control 
the propagation of information according to a security policy. A 
well-known policy addressed in almost every IFC system is non¬ 
interference: publicly-readable program results must not depend 
on secret inputs. This policy preserves confidentiality of sensitive 
data [15]. 

To enforce information flow restrictions corresponding to secu¬ 
rity policies such as non-interference, every piece of data is asso¬ 
ciated with a label, including the labels themselves. Labels form 
a lattice [9] with partial order C (pronounced “can flow to”) gov¬ 
erning the allowed flows. A lattice can be as simple as a few secu¬ 
rity levels. For instance, the three labels L, M, and H, respectively 
denoting unclassified, secret and top secret levels, form the lattice 
L C H C H. An IFC system such as our LIO library prohibits a 
computation running with security level M from reading top secret 
data (labeled H) or writing to public channels (labeled L). Dual to 
such confidentially policies are integrity policies [6], which use the 
partial order on labels to enforce restrictions on writes. 

Our library is polymorphic in the label type, allowing different 
types of labels to be used. Custom label formats can be created by 
defining basic label operations: the can flow to label comparison 
(□), a function computing the join of two labels (U), and a function 


computing the meet of two labels (n). Concretely, label types are 
instances of the Label type class: 


class (Eq 1) 
leq :: 1 —1 


=>■ Label 1 where 
1 —» Bool — Can flow 
1 ->• 1 — Join (U) 

1-11 — Meet (n) 


CO 


For any two labels Li and La, the join has the property that L; C 
(Li U La), i = 1,2, while the meet has the property that (Li n 
L 2 ) U Li, i = 1, 2. In this section we present examples using the 
simple three-point lattice introduced above, or a generic/abstract 
label format; Section 3 details DC labels, a new, practical label 
format used to implement AChair. 

Compared to existing systems, LIO is a language-based/foafing- 
label system, inspired by IFC operating systems [39, 40]. In a 
floating-label system, the label of a computation can rise to ac¬ 
commodate reading sensitive data (similar to the program counter 
(pc) of more traditional language-based systems [33]). Specifically, 
in a floating-label system, a computation C with label Lc wish¬ 
ing to observe an object labeled Lr must raise its label to the join, 
Lc LI Lr, of the two labels. Consider, for instance, a simple AChair 
review system computation executing on behalf of a user, Clarice, 
with label Lc that retrieves and prints a review labeled Lr, as 
identified by R : 


readReview ii do — Lc 

rv <— retrieveReview R — Lc U Lr 
printLabeledCh rv — Lc U Lr 


The computation label (initially Lc) is shown in the comments, on 
the right. Internally, the retrieveReview function is used to retrieve 
the review contents rv, raising the computation label to Lc U Lr to 
reflect the observation of confidential data. This directly highlights 
the notion of a “floating-label”: a computation’s label effectively 
“floats above” the labels of all objects it observes. Moreover, this 
implies that a computation cannot write below its label; doing so 
could potentially result in writing secret data to public channels. 

To illustrate the way floating labels restrict data writes, con¬ 
sider the action following the review retrieval: printLabeledCh rv. 
The trusted printLabeledCh function returns an action that writes 
the review content rv to an output channel, permitting the output 
channel label Lo. The output channel label Lo is dynamically 
set according to the user executing the computation. Specifically, 
Lo is carefully set as to allow for printing out all but the conflict¬ 
ing reviews. For example, if Clarice is in conflict with review R 
then Lo is set such that Lr % Lo- Since the computation la¬ 
bel directly corresponds to the labels of the data it has observed, 
printLabeledCh simply checks that the computation label flows 
to the output channel. In the example above, the trusted function 
checks that Lc U Lr C Lo before printing to (standard) output 
channel O. 

As already mentioned, in contrast to other language-based sys¬ 
tems, LIO also associates a clearance with each computation. This 
clearance sets an upper bound on the current floating label within 
some region of code. For example, code executing with a secret (M) 
clearance can never raise its label to read top secret data (labeled 
H). The notion of clearance can also prevent Clarice from retrieving 
(and not just printing) the contents of a conflicting review R by set¬ 
ting the computation’s clearance to Lp such that Lr % Lp. When 
the action retrieveReview R attempts to raise the current label to 
Lc U Lr to retrieve the review contents, the dynamic check will 
fail because Lc U Lr % Lp. For flexibility, the output channel 
label can simply be Lo = T, allowing any information that can be 
retrieved to be written to the output channel. 

Additionally, clearance can be used to prevent Clarice from 
using termination as a covert channel. For example, the following 
code can be used to leak conflicting-review information: 



leakingRetriveReview r = do 
rv < retrieveReview r 

then forever (return rv) 

However, using clearance, we prevent such leaks by setting the 
clearance and review labels in such manner that retrieveReview 
fails when raising the computation label to retrieve conflicting 
reviews. 

2.2 Library Interface 

LIO is a termination-insensitive [2] and flow-sensitive [20] IFC 
library that dynamically enforces information flow restrictions. At 
a high level, LIO defines a monad called LID, intended to be used 
in place of 10. The library furthermore contains a collection of LIO 
actions, many of them similar to 10 actions from standard Haskell 
libraries, except that they contain label checks that enforce IFC. 
For instance, LIO provides file operations like those of the standard 
library, but confining the application to a dedicated portion of the 
file system where a label is stored along with each file. 

To implement the notion of floating label bounded by a clear¬ 
ance, our library provides LIO as a state monad that uses 10 as 
the underlying base monad and it is parametrized by the type of 
labels. The state consists of a current label L cm , i.e., the computa¬ 
tion’s floating label, and a current clearance Ccm, which is an upper 
bound on L cm , i.e., L cur C C cu r. Specifically, the (slightly simplified) 
LID monad can be defined as: 

newtype Label 1 =>■ LIO 1 a = LIO (StateT (1, 1) 10 a) 

where the state corresponds to the ( L CUT . Ccur) pair. To allow for the 
execution of LIO actions, our library provides a function (evaiLlO) 
that takes an LIO action and returns an 10 action which, when ex¬ 
ecuted, will return the result of the IFC-secured computation. It is 
important to note that untrusted LIO code cannot execute 10 com¬ 
putations by binding 10 actions with LIO ones (to bypass IFC re¬ 
strictions), and thus effectively limits evaiLlO to trusted code. Ad¬ 
ditionally, using evalLIO, (trusted) programmers can easily, though 
cautiously, enforce IFC in parts of an otherwise IFC-unaware pro- 

The current label provides means for associating a label with 
every piece of data. Hence, rather than individually labeling def¬ 
initions and bindings, all symbols in scope are protected by L c ur 
(when a single LIO action is executed). Moreover, the only way to 
read or modify differently labeled data is to execute actions that 
internally access restricted symbols and appropriately validate and 
adjust the current label (or clearance). 

However, in many practical situations, it is essential to be able to 
manipulate differently-labeled data without monotonically increas¬ 
ing the current label. For this purpose, the library additionally pro¬ 
vides a Labeled type for labeling values with a label other than L C m. 
A Labeled, polymorphic in the label type, protects an immutable 
value with a specified label (irrespective of the current label). This 
is particularly useful as it allows a computation to delay raising 
its current label until necessary. For example, an alternative ap¬ 
proach to the above retrieveReview (called retrieveReviewAlt) 
retrieves the review, encapsulates it as a Labeled value, and returns 
the Labeled review, leaving the current label unmodified. This ap¬ 
proach delays the creeping of current label until the review con¬ 
tent, as encapsulated by Labeled, is actually needed, for instance, 
by printLabeledCh. 

We note that LIO can be used to protect pure values in a similar 
fashion as Labeled. However, the protection provided by Labeled 
allows for serializing labeled values and straight forward inspec¬ 
tion by trusted code (which should be allowed to ignore the pro¬ 
tecting label). Unlike LIO, Labeled is not a monad. Otherwise, the 


monad instance would allow a computation to arbitrarily manipu¬ 
late labeled values without any notion of the current label or clear¬ 
ance, and thus possibly violate the restriction that LIO computa¬ 
tions should not handle values below their label and above their 
clearance. Moreover, such instance would require a definition for a 
default label necessary when lifting a value with return. Instead, 
our library provides several functions that allows for the creation 
and usage of labeled values within LIO. Specifically, we provide 
(among other) the following functions: 

► label :: Label 1 =M —> a —f LIO 1 (Labeled 1 a) 

Given a label l such that L cm E l C C cm and a value v, the 
action label l v returns a labeled value that protects v with l. 

► unlabel :: Label 1 ^-Labeled 1 a -iLIO 1 a 
Conversely, the action unlabel lv raises the current label 
(clearance permitting) to the join of lv’s label and the current 
label, returning the value with the label removed. Note that the 
new current label is at least as high as lv’s label, thus protecting 
the confidentiality of the value. 

► toLabeled :: Label 1 =>1 -> LIO 1 a -S-LI0 1 (Labeled 1 a) 
Given a label l such that L cur C l C C cm and an LIO action m, 
toLabeled l m executes m without raising L cm . However, in¬ 
stead of returning the result directly, the function returns the 
result of m encapsulated in a Labeled with label l. To preserve 
confidentiality (see Section 4 for further details), action m must 
not read any values with a label above l. We can implement 
toLabeled as follows: 

toLabeled 1 m = do 

( '.L' cm , Ccuj) <- get — Save context 
res <— m — Execute action 

(Lcm, _) <— get — Get inner context 

unless (Lcm E 1) fail — Check IFC violation 
put (L' cm , C' ur ) — Restore context 

IRes <r- label 1 res — Encapsulate result 

In monadic terms, toLabeled is an environment-oriented action 
that provides a different context for a temporary bind thread, 
while unlabel is a state-oriented action that affects the current 
bind thread. 

► labelOf :: Label 1 ^Labeled 1 a ->1 

If lv is a labeled value with label l and value v, labelOf lv 
returns l. 

The formal semantics of these functions are given in Section 4 (see 
Figure 4); in this section, we illustrate their functionality and use 
through examples. 

Consider the previous example of readReview. The internal 
function retrieveReview takes a review identifier R and returns the 
review contents. This implies that, internally, retrieveReview has 
access to a list of reviews. These reviews are individually protected 
by a label, where the addition of a new review to the system can be 
implemented as: 
addReview R L R rv = do 
r <- label L R rv 
addToReviewList R r 

where the addToReviewList simply adds the Labeled review to 
the internal list. The implementation of retrieveReview directly 
follows: 

retrieveReview R = do — L c ur = Lc 
r <— getFromReviewList R — L cur = Lq 
rv ■*— unlabel r — L C m = Lq U L r 

return rv — L c ur = Lc U L R 

where the getFromReviewList retrieves the Labeled review from 
the internal list and unlabel removes the protecting label, and 
raises the current label to reflect the read. 


We previously alluded to an alternative implementation of 
retrieveReview which, instead, returns the labeled review content 
while keeping the current label the same. As getFromReviewList 
is a trusted function and not directly available to untrusted users, 
such as Clarice, retrieveReviewAit can be implemented in terms 
of toLabeled and retrieveReview: 

Lew = L c 
Lew = Lc 
— Lcur = Lc u Lr 
— Lew = L c U L r 
Lew = L C 

Note that although the current label within the inner computation is 
raised, the outer computation’s label does not change—instead the 
review content is protected by {Lc LI Lr). Hence, only when the 
review content is actually needed, unlabel can be used to retrieve 
the content and raise the computation’s label accordingly: 

readReviewAlt R — do — Lew = Lc 

X •<— retrieveReviewAit R — L CUT = Lc 

— Perform other computations — Lew — L' c 

rv <— unlabel r — L cur = L' c U Lr 

printLabeledCh rv — L cur = L' c LI Lr 

Our library also provides labeled alternatives to iORefs and 
files. Specifically, we provide labeled references Ref l a that are 
created with newRef, read with readRef, and written to with 
writeRef. When creating or writing to a reference with label Lr, 
it must be the case that L cur C Lr C C cur , while reading raises 
Lew to Lew U Lr C Cew. The rules for file operations follow 
identically, however writing to a file also implies observation (since 
the write can fail) and so the current label is raised in both cases. 
Finally, though beyond the scope of this paper, the library provides 
support for privileges. Privileges allow LIO code to operate under 
a more permissive C relation, but still more restricting than simply 
allowing the execution of arbitrary 10 actions. 

3. AChair 

To demonstrate the flexibility of our dynamic information flow 
library, we present AChair, a simple API (built on the examples of 
Section 2) for implementing secure conference reviewing systems. 
In general, a conference reviewing system should support various 
features (and security policies) that a program committee can use 
in the review process; minimally, it should support: 

► Paper submission: ability to add new papers to the system. 

► User creation : ability to dynamically add new reviewers. 

► User login : a means for authenticating users. 

► Review delegation: ability to assign reviewers to papers. 

► Paper reading: means for reading papers. 

► Review writing: means for writing reviews. 

► Review reading: means for reading reviews. 

► Conflict establishment: ability to restrict specific users from 
reading conflicting reviews. 

Even for such a minimal system, a number of security concerns 
must be addressed. First, only users assigned to a paper may write 
the corresponding reviews. Second, information from the review of 
one paper should not leak into a different paper’s review. Third, 
a reviewer should not be permitted to modify the review of a pa¬ 
per that she/he is not assigned to review. And, fourth, users should 
not received any information regarding papers for which they have 
conflicts. We establish these four policies as non-interference poli¬ 
cies for the confidentiality and integrity of reviews. We note that, 
although enforcing additional security properties is desirable, these 
four policies are sufficient when implementing a minimalistic and 
fair review system. 


AChair’s API provides the aforementioned security policies by 
applying information flow control. Following the examples of Sec¬ 
tion 2, we take the approach of enforcing IFC when writing to 
output channels, and thus the security for the above policies cor¬ 
respond to that of non-interference, i.e., secret data is not leaked 
into less secret channels/reviews. We do, however, note that the al¬ 
ternative, clearance restricting approach of Section 2, can be imple¬ 
mented and thus enforce the security policies by confinement rather 
than non-interference (see Section 5). Before delving into the de¬ 
tails of the AChair, we first introduce the specific label format used 
in the implementation. 

3.1 DC Labels 

AChair is implemented using Disjunction-Category (DC) labels, a 
new label format especially suitable for systems with mutually dis¬ 
trusting parties. DC labels can be used to express a conjunction 
of restrictions on data, which allows for the construction of poli¬ 
cies that reflect the concern of multiple parties. Such policies are 
expressed by leveraging the notions of principals and Disjunction 
Categories (henceforth just categories). 

A principal is a string representation of a source of authority 
such as a user, a group, a role, etc. To ensure egalitarian protection 
mechanisms, any code is free to create principals. 

A category is an information-flow restriction specifying the set 
of principals that own it. Each category is denoted as a disjunction 
of its owners; for example, the category owned by principals Pi and 
P2 is written as [Pi V P2]. Additionally, categories are qualified to 
be secrecy or integrity categories. A secrecy category restricts who 
can read, receive, or propagate information; an integrity category 
specifies who can modify a piece of data. 

A DC label L = {S, I) is a set S of secrecy categories and 
a set I of integrity categories. All categories must be satisfied 
in order to allow information to flow and thus we write each 
set as a conjunction of categories. For example, the DC label 
({[Pi V P2] A [P2 V P3]} , {[P4]}) has two secrecy categories and 
a single integrity category. Data with a DC label Li can be prop¬ 
agated to an endpoint having a DC label L2 if the restrictions 
imposed by Li are uphold by L2. We formalize this notion using 
the C-relationship as follows. 

Definition 1 (Can flow to). Given any two DC labels L\ = 
(Si,Ii) and L 2 = (S2, h), and interpreting each principal as 
a Boolean variable named according to the content of the string 
itself, we have 

Vci G 5i.3c2 G S'2 : C2 »# Cl Vc 2 G I 2 3ci G P : Ci => c 2 
(Si,h)Q(S 2 ,I 2 ) ’ 

where => denotes Boolean implication. 

From now on, when we refer to a principal P, it can be in¬ 
terpreted as a string or Boolean variable depending on the con¬ 
text. As an example of the use of C-relationship, the DC label 
({[Pi V P 2 ] A [P 2 V P 3 ]} , {[P 4 ]}> C ({[Pi] A [P 3 ]} , {[P 4 V P 6 ]}> 
since Pi => Pi VP2, Pi => P2VP3, and P 4 => P 4 VP6. Intuitively, 
the higher we move in the C-relationship, the more restrictive the 
secrecy category becomes, while the integrity category, on the other 
hand, changes into a more permissive one. Additionally, we note 
that if a label contains a category that is implied by another, the 
latter is extraneous, as it has no effect on the value of the label, and 
can be safely removed. 

The join and meet for labels Li = (Si,Ii) and L2 = {S 2 ,I 2 ) 
are respectively defined as follows: 

Li U L 2 = (reduce(Si A S 2 ), reduce(P V I 2 )) 

Li n L 2 = (reduce(Si V S 2 ), reduce(P A I 2 )) 


retrieveReviewAit R = do 

r <— toLabeled (Lc LI Lr) $ do — 
rv -t— retrieveReview R 



Here, reduce removes any extraneous categories from a given set 
and A and V denote the conjunction and disjunction of two cate¬ 
gory sets viewed as Boolean formulas of principals in conjunctive 
normal form. 

In the context of the well-known DLM [28], a DC label se¬ 
crecy category of the form [Pi V P2 V ■ ■ ■ V P„] can be in¬ 
terpreted as the (slightly modified) DLM label component/policy 
{Pi, P 2 ,..., P n : Pi, P 2 ,..., P n }, where principals Pi, . .., P n 
are both the owners and readers. Although a DLM component con¬ 
sists of a single owner, which does not need to be part of the reader 
list, a DC label component (category) consists of multiple owners 
which are also the (only) readers. Using this slightly modified no¬ 
tion of a label component, a DLM label (set of components) loosely 
corresponds to our notion of a label (conjunction of disjunctions). 
Readers interested in the formal semantics of DC labels and the 
comparison with DLM can refer to http: //www. scs. Stanford. 
edu/~deian/dclabel for further details. 

3.2 DC Labels in AChair 

In this section we describe the data structures and the role of DC 
labels (from now on just labels) in AChair. 

AChair provides an API to build review systems for the func¬ 
tionalities described in Section 3. Intuitively, the API just sup¬ 
plies administrators and reviewers with functions for querying re¬ 
view entries and modifying user accounts. Technically speaking, 
AChair runs over an underlying state monad that stores informa¬ 
tion regarding reviews and users. 

Review entries A review entry is defined as a record consisting of 
a paper id, a reference to the corresponding paper, and a reference 
to the shared review ‘notebook’. Specifically, a review entry is 
defined as 

data ReviewEnt = ReviewEnt { paperld :: Id 

, paper :: DCRef Paper 

, review :: DCRef Review > 

where DCRef is a labeled reference using DC labels. In other words, 
type DCRef a = Ref DCLabel a. Note that this differs from the 
examples of Section 2, in which the reviews were simply Labeled 

Reading and writing papers Upon logging in, users are allowed 
to read and print out any paper by providing the paper id. The label 
of the reference paper in the ith-review entry is set to ({} , {[Hi]}). 
Observe that the secrecy categories is empty (we interpret the 
empty category as the true Boolean value), thus allowing any func¬ 
tion (without other integrity categories in its label) to read the pa¬ 
per by reading the reference content, i.e., the paper. This label does, 
however, restrict the modification of the paper to code running in 
a process that owns the integrity category Pi and can therefore run 
with the category [Pi] in the integrity set of its current label. Only 
a trusted administrator is allowed to own such principals. Conse¬ 
quently, reviewers’ code cannot modify the paper because their cur¬ 
rent label (assigned by the trusted login procedure) never includes 
Pi in their integrity set. 

Reading and writing reviews Similarly, reviewers’ code is al¬ 
lowed to access any reviews written to any reference review. How¬ 
ever, once a review has been read, its contents must not be written 
to another paper’s review. We fulfill this requirement by identify¬ 
ing, using labels, when a given piece of code reads a certain review. 
More specifically, we label the reference review in the ith-review 
entry as ({[Hi]}, {[Hi]}). As a consequence, when a function 
wishes to read the review for entry i, it must raise its current label 
as to include category [ Ri ] in its secrecy and integrity sets (clear¬ 
ance permitted). Once a process has been tainted as such, it will not 
be able to modify the contents of another paper’s review since the 
integrity category [Hi] will cause the current label’s integrity set to 


contain Ri in every category and (Ri V C) =fc- Rj for any C and 
i / j. Consider, for instance, a reviewer’s code that has the current 
label set (by the trusted login procedure) to ({[Hi]} , {[Hi]}), i.e., 
in the process of reviewing paper Pi. If the code reads another re¬ 
view with label Lj = ({[H,]} , {[Hj]}), the current label is then 
updated to L = ({[Hi] A [H,]} . {[Hi V H,]}), which clearly im¬ 
plies that L % Lj. The integrity category [Ri] restricts the modi¬ 
fication of the review to processes that own Hi. In this case, how¬ 
ever, the process running reviewers’ code, assigned to review paper 
i, contains, at least initially, category [Hi] in the integrity set of its 
current label. 

Users A reviewer is defined as a record consisting of a unique 
user name, password (used for authentication), and two disjoint 
sets of paper ids (in our implementation these are simple lists). 
One set corresponds to the user’s conflicting papers, the second 
set corresponds to the papers the user has been assigned to review. 
Concretely, we define a user as follows: 

data User = User { name :: Name 

, password :: Password 

, conflicts :: [Id] 

, assignments :: [Id] } 

A user is authenticated using the name and password creden¬ 
tials. Upon logging in, the code of the reviewer assigned to pa¬ 
pers 1 ,... ,n is executed with the current label initially set to 
({} > {[Hi] A • • • A [H„]}), where Ri is the principal correspond¬ 
ing to review entry i. The current clearance is set to (ALL, {}). The 
special category set ALL (denoting the conjunction of all possible 
categories) in the clearance allows the executing code to (raise its 
current label and) read any data, while the integrity categories in the 
current label allow the process to only write to assigned reviews. 
Note, however, that in our case all reviewers append their review to 
the same review “notebook” and thus a write implies a read. Hence, 
to allow a reviewer to effectively perform a write-only operation, 
the process must execute the append function using toLabeled. 
We note the user is exposed to a function that appends to the re¬ 
view rather than directly writing to it, because multiple users are 
assigned to review the same paper and one should not be allowed 
to overwrite the work of another (using privileges a more elegant 
solution can easily be implemented). 

Conflicts Following the readReview examples of Section 2, we 
restrict the reading, or more specifically, printing of a review to 
those reviewers in conflict with the paper. Although every user is 
allowed to retrieve a review, they cannot observe the result unless 
they write it to an output channel (in our simple example this 
corresponds to the standard output). Hence, code running on behalf 
of a user (determined after logging in) can only write to the output 
channel (using printLabelCh) if the current label L can flow to 
the output channel label L a . Using the set of conflicting paper 
ids, for every user, we dynamically assign the output channel label 
L„ = (S a ,{}), where S„ = {[Hi] A ■ • ■ A [H»] A [H„+i V 
CONFLICT] A • ■ • A [Hjv V CONFLICT]} and Hi where i = n + 
1 ,... ,N are the principals corresponding to all the review entries 
in the system (at the point of the print) that the authenticated 
user conflicts with. Here, CONFLICT corresponds to a principal 
that none of the users own (similar to Pi used in the labels of 
paper references). For each conflicting paper i, we create a category 
[Hi V CONFLICT], To observe the properties of this label, consider 
the case when executing code reads a conflicting paper Hi. In this 
situation, the current label is raised to L = ({[Hi] A •••},{■•■ }), 
and subsequently when attempting to write to the output channel, it 
is the case that L % L a . For L IZ L a to hold true, there must be a 
category in L a that implies [Hi]. However, due to the conflict, the 
only category containing Hi in the channel label’s secrecy category 
is [Hi V CONFLICT] (and clearly [Hi V CONFLICT] ^ [Hi]), which 




asserts that conflicting data cannot flow to the output channel. 
We further highlight that the channel label permits non-conflicting 
reviews j to be observed by including the corresponding category 
[jRj] without principal CONFLICT. 

3.3 Implementation 

In this section we present the API provided by AChair. As the 
main goal of AChair is to demonstrate the flexibility and power 
of our dynamic information flow library, we do not extend our 
example to a full-fledged system; the API can, however, be used 
to build relatively complex review systems. Below, we present the 
details of the AChair functions, which return actions in the RevLlO 
monad. This monad is a State monad defined using the State monad 
transformer with LID as the base monad, and a state consisting 
of the system users, review entries, and name of the user that the 
executing code is running on behalf of. 

System administrator interface A AChair administrator is pro¬ 
vided with several functions that dynamically change the system 
state. Of these, we detail the most interesting cases below. 

► addPaper :: Paper vRevLIO Id 

Given a paper, it creates a new review entry for the paper and 
return the paper id. Internally, addPaper uses a function similar 
to addReview of Section 2. 

► addUser :: Name —^Password —iRevLIO 0 

Given a unique user name and password, it adds the new user. 

► addAssignment ::Name —>Id —iRevLIO 0 

Given a user name and paper id, it assigns the user to review the 
corresponding paper. The user must not already be in conflict 
with the paper. 

► addConf lict ::Name ->Id -> RevLIO O 

Given a user name and paper id, it marks the user as being in 
conflict with the paper. As above, it must be the case that the 
user is not already assigned to review the paper. 

► asUser :: Name —>RevLI0 O —»RevLI0 0 

Given a user name, and user-constructed piece of code, it firsts 
authenticates the user and then executes the provided code with 
the current label and clearance of the user as described in Sec¬ 
tion 3.2. After the code is executed, the current label and clear¬ 
ance are restored and any information flow violations are re¬ 
ported. 

Reviewer interface The reviewer, or user, composes an untrusted 
RevLIO computation (or action) that the trusted code executes using 
asUser. Such actions may be composed using the following inter- 

► findPaper :: String RRevLIO Id 

Given a paper title, it returns its paper id, or fails if the paper is 

► readPaper :: Id —i RevLIO Paper 

Given a paper id, the function returns an action which, when 
executed, returns the paper content. 

► readReview ::Id -iRevLIO () 

Given a paper id, the function returns an action which, when ex¬ 
ecuted, prints the review to the standard output. Its implementa¬ 
tion is similar to the example of Section 2, except operating on 
references. 

► appendToReview ::Td ^Content >RevLI0 () 

Given a paper id and a review content, the function returns an 
action which, when executed, appends the supplied content to 
the review entry. Since there is no direct observation of the 
current review content, and to avoid label creep, the function, 
internally, uses toLabeled. 

An IFC violation results in an exception (not-catchable by un¬ 
trusted code) being thrown (in the semantics presented in Section 4, 


Figure 1 An example of code using AChair API. 


module Admin where 

import Alice 
import Bob 

main = evalRevLIO $ do 

— Adding users to system 
addUser "Alice" "password" 

— Adding papers to system 

pi addPaper "Flexible Dynamic..." 
p2 < addPaper "A Static..." 

— Assign reviewers 
addAssignment "Alice" pi 
addAssignment "Alice" p2 

— Executing Alice’s code 
asUser "Alice" $ aliceCode 

— Adding new users to system 
addUser "Bob" "password" 

— Assign reviewers and conflicts 
addAssignment "Bob" p2 
addConflict "Bob" pi 

— Executing Bob’s code 
asUser "Bob" $ bobCode 

module AliceCode where 

aliceCode = do 

pi findPaper "Flexible Dynamic..." 
p2 t— findPaper "A Static..." 
readPaper pi 

appendToReview pi "Interesting work!" 
readPaper p2 
readReview p2 

appendToReview p2 "What about adding new users?" 
return O 

module BobCode where 
bobCode = do 

pi t— findPaper "Flexible Dynamic..." 
p2 i — findPaper "A Static..." 
appendToReview p2 "Hmm, IFC.." 
readReview pi — IFC violation attempt 
return () 


the program gets “stuck”). Figure 1 shows a simple example us¬ 
ing the AChair API. In this example, Alice is assigned to review 
two papers. She does so by reading each paper (for the second, she 
also reads the existing reviews) and appending to the shared review. 
Bob, on the other hand, is added to the system after Alice’s code 
is executed. Bob first writes a review for paper 2 and then attempts 
to violate IFC by trying to read (and write to the output channel) 
the reviews of paper 1. Though his review is appended to the cor¬ 
rect paper, the review of the first paper is suppressed. We finally 
note that although the example is quite simple, it illustrates the use 
of the AChair primitives that may be used to implement a usable 
paper review system. 





Figure 2 Formal syntax for terms, expressions, and types. 


Label: 

Z 

Address: 

a 

Term: 

v::= true | false | () | Z | a | * | Ax.e | (e, e) 

| fixe | Lb ue | (e) LI ° | • 

Expression: 

e ::= v \ e e \ Tti e | if e then e else e 

| let x = e in e | return e | e »= e 
| label e e | unlabel e | toLabeled e e 
| newRef e e | readRef e | writeRef e e 
| lowerClr e | getLabel | getClearance 
| labelOf e | labelOfRef e 

Type: 

r ::= Bool () tAt (t,t) 

| £ | Labeled £ t | LIO £ r | Ref £ r 

Store: 

<fi : Address -A Labeled £ r 


4. Formal Semantics for LIO 

This section formalizes our library for a simple call-by-name 1 
A-calculus extended with Booleans, unit values, pairs, recursion, 
references, and the monadic operations for LIO. Figure 2 provides 
the formal syntax of the considered language. Syntactic categories 
v, e, and r represent terms, expressions, and types, respectively. 
Terms are side-effect free while expressions denote (possible) side- 
effecting computations. 

In the syntax category v, symbol true and false represent 
Boolean values. Symbol 0 represents the unit value. Symbol £ de¬ 
notes security labels. Symbol a represent memory addresses in a 
given store. Terms include variables (a;), functions (Xx.e), tuples 
(e, e), and recursive functions (fix e). Three special syntax nodes 
are added to this category: Lb v e, (e) LI °, and •. Node Lb v e de¬ 
notes the run-time representation of a labeled value. Similarly, node 
(e) LID denotes the run-time representation of a monadic LIO com¬ 
putation. Node • represents an erased term (explained in Section 
5). None of these special nodes appear in programs written by users 
and they are merely introduced for technical reasons. 

Expressions are composed of values ( v ), function applications 
(e e), pair projections (n. t e), conditional branches (if e then e 
else e), and local definitions (let x = e in e). Additionally, 
expressions may involve operations related to monadic computa¬ 
tions in the LIO monad. More precisely, return e and e »= e 
represent the monadic return and bind operations. Monadic opera¬ 
tions related to the manipulation of labeled values inside the LIO 
monad are given by label, unlabel, and toLabeled. Expression 
label ei e% creates a labeled value that guards e2 with label e\. 
Expression unlabel e acquires the content of the labeled value 
e while in a LIO computation. Expression toLabeled ei e2 cre¬ 
ates a labeled value, with label ei, of the result obtained by eval¬ 
uating the LIO computation e2. Non-proper morphisms related to 
creating, reading, and writing of references are respectively cap¬ 
tured by expressions newRef, readRef, and writeRef. Expres¬ 
sion lowerClr e allows lowering of the current clearance to e. Ex¬ 
pressions getLabel and getClearance return the current label 
and current clearance of an LIO computation. Finally, expressions 
labelOf e and labelOf Ref e respectively obtain the security la¬ 
bel of labeled values and references. 

We consider standard types for Booleans (Bool), unit (()), 
pairs (t,t), and function (r —> r) values. Type £ describes se¬ 


1 For clarity, we use a call-by-name instead of call-by-need calculus; exten¬ 
sion to the latter is straight forward, as shown in [23]. 


curity labels. Type Labeled £ r describes labeled values of type r 
where the label is of type £. Type LIO £ r represents monadic LIO 
computations, with a result type r and the security labels of type l. 
Type Ref £ r describes labeled references, with labels of type £, to 
values of type t. 


Figure 3 Typing rules for terms. 

, r(a) = Labeled £r 

T h ei : £ r F e 2 : r 

r h a : Ref £ r 

T F Lb ei e 2 : Labeled £ r 

r F e : t 

T h (e) LID : LIO £ r 

TF • : r 


The typing judgments have standard form T h e : t, such 
that expression e has type r assuming the typing environment T ; 
we use r for both variable and store typings. The typing rules for 
several terms are shown in Figure 3; the typing for the remaining 
terms and expressions are standard and we therefore do not describe 
them any further. We, however, note that, different from previous 
work [12, 32], we do not require to use any of the sophisticated 
features of Haskell’s type-system, a direct consequence of our 
dynamic approach. 

The LIO monad presented in Section 2 is implemented as a State 
monad. To simplify the formalization and description of expres¬ 
sions, without loss of generality, we make the state of the monad 
part of a run-time environment. More precisely, for a given LIO 
computation, the symbol E denotes a run-time environment that 
contains the current label, written E.lbl, the current clearance, 
written E.clr, and store, written E.<p. A run-time environment E 
and LIO computation form a configuration (E, e). Given a config¬ 
uration (E, e), the current label, clearance, and store when starting 
evaluation e is given by E.lbl, E.clr, and E.ci, respectively. 

The relation (E, e) —> (E', e') represents a single evaluation 
step from expression e, under the run-time environment E, to 
expression e' and run-time environment E'. We say that e reduces 
to e' in one step. We define such relation in terms of a structured 
operational semantics via evaluation contexts [14]. 

The reduction rules for the core simply-typed A-calculus are 
standard and therefore omitted. We note that substitution ([ei /x\ e2) 
is defined in the usual way: homomorphic on all operators and re¬ 
naming bound names to avoid captures. Figure 4 presents the eval¬ 
uation contexts and non-standard reduction rules for our language. 
These rules guarantee that programs written using our approach 
fulfill non-interference, i.e., confidential information is not leaked, 
and confinement, i.e., a computation cannot access data above the 
clearance. 

The main contribution of our language are the primitives label, 
unlabel, and toLabeled. Rule (Lab) generates a labeled value 
if and only if the label is between the current label and clearance of 
the LIO computation and thus guaranteeing containment properties 
(see Section 5). Rule (unLab) provides a method for accessing 
the content e of a labeled value Lb l e in LIO computations. When 
the content of a labeled value is “retrieved” and used in a LIO 
computation, the current label is raised (E' = E[lbl ha /'], 
where t = E.lbl U Z), capturing the fact that the remaining 
computation might depend on e. Rule (toLab) deserves some 
attention. We write —for the reflexive and transitive closure of 
—>. Expression toLabeled l e is used to execute the provided 
LIO computation e until completion ((E, e) —>* (E', (u) LI0 )) 
and wraps its result v into a labeled value with label l. Observe 
that the label l needs to be an upper bound on the current label 
for the evaluation of computation e (E'.lbl C Z). Specifying 
label Z is responsibility of the programmer. The reason for this is 
due to the fact that security labels are protected by the current 














Figure 4 Semantics for non-standard constructs. 

E '[•] | Lb E e \ E e \ ir t E | if E then e else e 

| return E \ E »= e 

| label E e | unlabel E | toLabeled E e 
| newRef E e | readRef E | writeRef E e 
| lowerClr E | labelDf E | labelDfRef E 

{^> -E[return v]) > (E, £J[(u) LID ]) 

(E,E[(v) a °»= e 2 ]>—1<£ ,E[e, v]) 

(Lab) 

E.lbl C Z E E.clr 

(E, i5[label Z e]) —4 (E, f?[return (Lb l e)]) 

(unLab) 

l' = E.lbl U l i'C E.clr E' = E[lbl h4 l'] 

(E, F/[unlabel (Lb Z e)]} —4 (£*, i5[return e]) 

(toLab) 

E.lbl C Z C E.clr (E, e) —4* (E', ( v) LI °) 

E'.lbl C 2 E" = E'[lbl 1-4 E.lbl, clr H- E.clr] 

(E, F/[toLabeled Z e]} —4 (£”, f?[label Z «]) 

(nRef) 

E.lbl C Z C E.clr E' = £.0[a 1-4 Lb l e] 
(E,i?[newRef l e]) —4 (E^ E [return a]) ^ 

(rRef) 

£.^>(a) = Lb l e 

l' = E.lbl U l i'C E.clr E' = E[lbl h4 l'] 

(£,-E[readRef a]) —4 (E / , E [return e]} 

(wRef) 

E.0(a) = Lb l e 

E.lbl C Z C E.clr E' = E ,<f>[a 1-4 Lb l e\ 

(E, f5[writeRef a e']) —4 (S', ^[return ()]) 

(lwClr) 

E.lbl g l C E.clr T,' = E[clr i-> Z] 

(E, i5[lowerClr Z]) —> (E', ^[return ()]} 

(CLAB) 

Z = E.lbl 

(E, i?[getLabel]) —> (E, £Z[return Z]} 

(cClr) 

l =* E.clr 

(E, B[getClearance]) —(E, i?[return Z]) 

(GLab) 

(E, £[labelOf (Lb Z e)]> —4 (E, E[l ]) 

(gLabR) 

e i= 

(E, B[labelOfRef a]> —> (E, S[labelOf e]> 

label, effectively making them public information accessible to 
any computation within scope (see rules (gLab) and (GLabR)). 
As a consequence, if toLabeled did not require an upper bound 
on the data to be observed within e, labels can be used to leak 
information. Recall that the current label and clearance of a given 
LIO computation can be changed dynamically. To illustrate this 
point, consider a computation whose current label is Zo, taking two 
(confidential) labeled values as arguments, with respective labels h 
and h such that h g Zo, i = 1,2. 

leak 1V1 1V2 = do 


1V3 <— toLabeled’ $ do 

vl unlabel 1V1 — Lcur = li 

if vl then return True 

else unlabel 1V2 — L c ur = I2 
return (labelOf 1V3) 

Therefore, if the returned value is Zi or Z2 (remember that labels 
are public information), information is directly leaked! To close this 
channel, programmers should provide an upper bound of the cur¬ 
rent label obtained when e finishes computing. Since our approach 
is dynamic, flow-sensitive, and sound, this may require non-trivial, 
and possibly complicated, static analysis in order to automatically 
determine the label for each call of toLabeled [31]. 

By using big-step semantics instead of an evaluation context of 
the form toLabeled l E, rule (toLab) does not need to rely on 
the use of trusted primitives or a stack for (saving and) restoring the 
current label and clearance when executing toLabeled. 

When creating a reference, newRef l e produces a labeled value 
that guards e with label l (Lb Z e) and stores it in the memory store 
(£' = E ,(j)[a i-4 Lb l e]). The result of this operation is the memory 
address a (return a). Observe that references are created only if 
the reference’s label (Z) is between the current label and clearance 
label of the LIO monad (E.lbl O l C E.clr). The restriction 
Z C E.clr is to assure that programs cannot manipulate or access 
data beyond their clearance (see Section 5). Rule (rRef) obtains 
the content e of a labeled value Lb l e stored in the address a. 
This rule raises the current label to the security level l' (E' = 
£[lbl 1-4 l'] where l' = E.lbl U Z). As in the previous rule, 
(rRef) enforces that the result of reading a reference is below the 
clearance (Z' g E.clr). Rule (wRef) updates the memory store 
with a new value for the reference (E' = £.©[«. 1-4 Lb l e']) as long 
as the label of the reference is above the current label and it does 
not exceed the clearance (E.lbl C l □ E.clr). If considering 
E.lbl as a dynamic version of the pc the restriction that the label 
of the reference must be above the current label (E.lbl C Z) is 
similar to the one imposed by [30], 

Rule (lwClr) allows a computation to lower the current clear¬ 
ance to l. This operation is particularly useful when trying to con¬ 
tain the access to some data as well as the effects produced by com¬ 
putations executed by toLabeled. Rules (CLAB) and (cClr) ob¬ 
tain the current label and clearance from the run-time environment. 
Finally, rules (GLab) and (GLabR) return the labels of labeled 
values and references. Observe that, regardless of the current label 
and clearance of the run-time environment, these two rules always 
succeed, effectively making labels public data. 

5. Soundness 

In this section we show that LIO computations satisfy two secu¬ 
rity policies: non-interference and containment. Non-interference 
shows that secrets are not leaked, while containment establishes 
that certain piece of code cannot manipulate or have access to cer¬ 
tain data. The latter policy is similar to the containment policies 
presented in [4, 24]. 

5.1 Non-interference 

As in [26, 32], we prove the non-interference property by using the 
technique of term erasure. Intuitively, data at security levels where 
the attacker cannot observe information can be safely rewritten to 
the syntax node •. For the rest of the paper, we assume that the at¬ 
tacker can observe data up to security level L. The syntactic term •, 
denoting an erased expression, may be associated to any type (re¬ 
call Figure 3). Function el, is responsible for performing the rewrit¬ 
ing for data at security level not lower than L. In most of the cases, 
the erasure function is simply applied homomorphically (e.g., 
£i(if E then e else e') = if £l(E) then ex,(e) else ei^e')). 
In the case of data constructors it is simply the identity function. 
















Figure 5 Erasure function for several terms, memory store and 
configurations. 

sl( 1) = 1 e L {a) = a 


environments, written E = E', is defined as the point-wise equality 
between mappings E and E'. 

Proposition 1 (Determinacy of —>). 


£i(Lb le) = | 


Lb l • l %L 

Lb Zei,(e) otherwise 


ez,(E.</>) = {(z,ez,(E.</>(a;)) : x € dom(E»} 
e i (E) = E[0^ et (E.^)] 


(el( E),«) E.lbl %L 

(ei,(E), ei,(e)) otherwise 


The two interesting cases for this function are when ei, is applied 
to a labeled value or a given configuration. In such cases, term 
erasing could indeed modify the behavior of the program. Figure 
5 shows the definition of el for several terms and configurations. 
A labeled value is erased if the label assigned to it is above L 
(ez, (Lb l e) = Lb l •, if l g L). Similarly, the computation per¬ 
formed in a certain configuration is erased if the current label is 
above L (ei,((E, e)) = (el{ E),«) if E.lbl % L). 

Following the definition of the erasure function, we introduce a 
new evaluation relation —>l as follows: 


(S, e) > {S', e') 
<E,e) —«*({£', e'» 


► For any expression e and run-time environment E such that 
(E, e) —> (E', e"), there is a unique term e' and unique 
evaluation context E such that e = E[e']. 

► If (E, e) —I (S', e') and (E, e) —> (E", e"), then e' = e" 
and E ' — E". 

Proof. By induction on expressions and evaluation contexts. □ 
Proposition 2 (Determinacy of— >l). If (E,e) — >l (E', e') 
and (E, e) —>l (E”, e"), then e' = e " and S r = E". 

Proof. From Proposition 1 and definition of el- □ 

The following proposition shows that the erasure function is ho¬ 
momorphic to the application of evaluation contexts and substitu¬ 
tion as well as that it is idempotent. 

Proposition 3 (Properties of erasure function). 

1. E L (E[e])=E L (E)[E L (e)l 

2. £x,([e 2 /a:]ei) = [££(e 2 )/a:]£z,(ei) 

3. EL{e L (e)) =E L {e) 

4. EL{e L {E))=e L {E) 

5. «(«(£)) -«(E) 

6. e l (el({ E,e») = ei ((E,e» 

Proof. From the definition of £l and by induction on expressions 
and evaluation contexts. □ 


Expressions under this relationship are evaluated in the same way 
as before, with the exception that, after one evaluation step, the 
erasure function is applied to the resulting configuration, i.e., run¬ 
time environment and expression. In that manner, the relation — 
guarantees that confidential data, i.e., data not below level L, is 
erased as soon as it is created. We write —>* L for the reflexive and 
transitive closure of — >l. 

Most results that prove 
non-interference pursue 
the goal of establishing 
a relationship between 
—t* and —>* L through 
the erasure function, as 
highlighted in Figure 1. 

Informally, the diagram 
establishes that erasing all 
secret data, i.e., data not 
below L, and then taking 
evaluation steps in —> l is the same as taking steps in —> and then 
erasing all the secret values in the resulting configuration. Observe 
that if information from some level above L is leaked by e, then 
erasing all secret data and then taking evaluation steps in — 
might not be the same as taking steps in —> and then erasing all 
the secret values in the resulting configuration. 

For simplicity, we assume that the space address of the memory 
store is split into different security levels and that allocation is 
deterministic. In that manner, the address returned when creating 
a reference with level l depends only on the references with level 
l already in the store. These assumptions are valid in our language 
since, similar to traditional references in Haskell, we do not provide 
any mechanisms for deallocation or inspection of addresses in the 
API. However, when memory allocation is an observable channel, 
the library could be adapted in order to deal with non-opaque 
pointers [17]. 

We start by showing that the evaluation relationship —> and 
—>l are deterministic. We note that e = e' means syntactic 
equality between expressions e and e!. Equality between run-time 


The next lemma establishes a simulation between —t and 
—>L for expressions that do not execute toLabeled. 

Lemma 1 (Single-step simulation without toLabeled). IfT \- e : 
t and (E, e) —>• (E', e') where toLabeled is not executed, then 
r he' : t and ez,((E, e)) —£t«E',e'». 

Proof. Subject reduction holds by showing that a reduction step 
does not change the types of references in the store E .<fi and then 
applying induction on the typing derivations. The simulation holds 
by simple case analysis on e. □ 

Using this lemma, we then show that the simulation is preserved 
when performing several evaluation steps. 

Lemma 2 (Simulation for expressions not executing toLabeled). 
IfT h e : r, (E, e) — >* (E', e') where there are no executions of 
toLabeled, then T h e' : r and sz,((E, e)) — el{{ E',e')). 
Proof. By induction on —> and applying Lemma 1. □ 

The reason for highlighting the distinction between expressions 
executing toLabeled and those not executing it is due to the fact 
that the evaluation of toLabeled involves big-step semantics (re¬ 
call rule (TOLab) in Figure 4). However, the next lemma shows the 
simulation between —>* and —>* L for any expression e, and it is 
proved by simple induction on the number of executed toLabeled. 

Lemma 3 (Simulation). IfT h e : r and (E, e) —*■* (E', e') then 
££«E,e» —►! ei «E',e'». 

Proof. By induction on the number of executed toLabeled and 
applying Lemma 2 for the base case. □ 


Figure 6 /.-equivalence for expressions. 

e «z, e' l □ L 1%L 

Lblett L Lble' Lb l e Lb l e 


We define /.-equivalence between expressions. Intuitively, two 
expressions are /.-equivalent if they are syntactically equal, modulo 


{E,e> -(E',e'> 

Jf h 

£l(( E,e» - >1 et({E', e')) 


Figure 1. Simulation between 













labeled values whose labels are above L. We use « j, to represent 
L-equivalence for expressions. Figure 6 shows the definition for 
labeled values. Considering the simple lattice: LCHCH and an 
attacker at level L, it holds that Lb H 8 « L Lb H 9, but it does not 
hold that Lb L 2 Lb L 3 or Lb H 8 « L Lb M 8. Recall that labels 
are protected by the current label, and thus (usually) observable by 
an attacker — unlike the expressions they protect, labels must be 
the same even if they are above L. The rest of «£ is defined as syn¬ 
tactic equality between constants (e.g., true ~/. true) or homo- 
morphisms (e.g., if e then ei else ei if e then ei else ei 
if e e', ei «z, ei, and e2 ei). 

Since our language encompasses side-effecting expressions, 
it is also necessary to define L-equivalence between memory 
stores. Specifically, we say that two run-time environments are 
i-equivalent if an attacker at level L cannot distinguish them: 
Definition 2 (L-equivalence for stores). 

iCLVJ'Ci \/a.T,.<f>(a) =U>len L E' 4(a) = Lb l' e 

E .4, Ri L S '.<j> 

Note that the L-equivalence ignores the store references with labels 
above L. Similarly, we define L-equivalence for configurations. 
Definition 3 (L-equivalence for configurations). 

e wl e T,.cj> E'.<£ 

E.lbl = S'.lbl E.clr = S'.clr E.lbl g L 

<E,e) {S', e) 

E 4 k. l E '.(j> E.lbl g L E'.lbl g L 
<E,e) (S', e) 

In the above definition, it is worth remarking that we do not 
require for expressions when the current label is not below L. 
This omission comes from the fact that e and e' would be reduced 
to • when applying our simulation between —>* and —>* L (recall 
Figure 5). 

The next theorem shows the non-interference policy. It essen¬ 
tially states that given two inputs with possibly secret information, 
the result of the computation is indistinguishable to an attacker. In 
other words, there is no information-flow from confidential data to 
outputs observable by the attacker. 

Theorem 1 (Non-interference). Given a computation e (with no •, 
( ) LI °, or Lb) where The: Labeledlr ->■ LlOi (Labeledi r'), 
environments Ei and E2 where Ei.cj b = E2 .0 = 0 , security label 
l, an attacker at level L such that l g L, then 
Veie2-(r h e» : Labeled £ f)i=ip 

A (m = Lb l e')i=1,2 A (Ei, ei) m (E 2 , e 2 > 

A (Ei, e ei) — ¥* (E'j, (Lb h e") 110 ) 

A (E2, e 62) —>* (Ei, (Lb l 2 ei) 110 ) 

=$> (Ei, Lb h ei) (Ei, Lb l 2 e'2) 

Observe that even though we assume that the input labeled values 
ei and e2 are observable by the attacker (l g L), they might 
contain confidential data. For instance, ei could be of the form 
Lb l (Lb l' true) where l * 1 g L. 

Proof. The L-equivalence (and, thus, the proof) directly follows by 
Lemma 3 and determinacy of— >l- □ 

5.2 Confinement 

In this section we present the formal guarantees that LIO computa¬ 
tions cannot modify data below their current label and manipulate 
information above their current clearance. These kind of properties 
are similar to the ones found in [4, 24], 


We start by proving that the current label of a LID computation 
does not decrease. 

Proposition 4 (Monotonicity of the current label). If T h e : r 
and (E,e) —(E',e'), then E.lbl g E'.Ibl. 

Similarly, we show that the current clearance of a LIO computation 
never increases. 

Proposition 5 (Monotonicity of the current clearance). IfY F e : r 
and (E,e) —(S', e'), then E'.clr g E.clr. 

Proposition 4 and 5 are crucial to assert that once a LIO com¬ 
putation reads confidential data, it cannot lower its current label to 
leak it. Similarly, a computation should not be able to arbitrarily in¬ 
crease its clearance; doing so would allow it to read any data with 
no access restrictions. 

Before delving into the containment theorems, we first define a 
store modifier that removes all store elements with a label above a 
given label l: 

(E.0)^ = E 4 \ {(a, Lb I' e) : a € dom (E .<f>) A Z g l'} 

PJhi 

In other words, this retains all the labeled references with a label 
below l, usually the current label. 

The first theorem states that LIO computations cannot create 
labeled values, new locations or modify memory cells below their 
current label ( no-write down). 

Theorem 2 (Containment imposed by the current label). Given 
labels l, l c , and l v , a computation e (with no •, ( ) LI °, or Lb) where 
The: Labeledi r —> LIO £ (Labeledi t), environment 
E[lbl i ->-1, clr !->■ lc] such that l g l c , and l g l v . 
r h ei : Labeled £ r 

A ei = Lb l v ei A (E, e ei) —(E', (Lb l v e") Lia ) 

=F (E = (E'.0)4.1 A ei = ei' 

Proof. The proof follows directly from Proposition 4, definition of 
the store modifier and induction on —>*. □ 

The theorem simply states that the computation cannot allocate or 
modify the store below l. Moreover the computation should only 
be able to return a labeled value below its current label that was 
provided as input, or by capture. 

Dual to Theorem 2, the next theorem captures the fact that 
LIO computations cannot compute on labeled values above their 
clearance. In other words, LIO computations cannot create, read, 
and write references or read and create contents for labeled val¬ 
ues above the clearance (recall that references store labeled val¬ 
ues). Again, we first define a store modifier; in this case, one that 
removes all store elements below a given clearance as follows: 
(E.0) t z = E.0 \ {(a, Lb l' e) : a € dom (E.0) A Z' g 1} 

(E.0) t i 

In other words, this retains all the labeled references with a label 
above l, usually the current clearance. 

Theorem 3 (Containment imposed by clearance). Given labels 

l, l c , and l v , a computation e (with no •, ( ) Lla , or Lb) where 
The: Labeled ( t -> LIO £ (Labeled £ t), environment 
E[lbl h-> l, clr !->■ lc] such that l g l c and l v g l c , 

T h ei : Labeledi t 

A ei = Lb l v ei A (E, e ei) —(E', (Lb l v e[) LI °) 

=k (E.0)tz c = (E'.0) t ; c A ei = ei 

Proof. Directly from Proposition 5, definition of the store modifier 
and induction on —>*. □ 








6. Related Work 

Heintze and Riecke [18] consider security for lambda-calculus 
where lambda-terms are explicitly annotated with security labels, 
for a type-system that guarantees non-interference. One of the 
key aspects of their work consists of an operator which raises the 
security annotation of a term in a similar manner to our raise of the 
current label when manipulating labeled values. Similar ideas of 
floating labels have been used by many operating systems, dating 
back to the High-Water-Mark security model [22] of the ADEPT- 
50 in the late 1960s. Asbestos [13] first combined floating labels 
with the Decentralized label model [28], 

Abadi et al. [1] develop the dependency core calculus (DCC) 
based on a hierarchy of monads to guarantee non-interference. In 
their calculus, they define a monadic type that “protects” (the con¬ 
fidentiality of) side-effect-free values at different security levels. 
Though not a monad, our Labeled type similarly protects pure 
values at various security levels. To manipulate such values, DCC 
uses a non-standard typing rule for the bind operator; the essence of 
this operator, in a dynamic setting with side-effectful computations, 
is captured in our library through the interaction of of Labeled, 
unlabel, and LIO. 

Tse and Zdancewic [36] translate DCC to System F and show 
that non-interference can be stated using the parametricity the¬ 
orem for System F. The authors also provide a Haskell imple¬ 
mentation for a two-point lattice. Their implementation encodes 
each security level as an abstract data type constructed from func¬ 
tions and binding operations to compose computations with per¬ 
mitted flows. Since they consider the same non-standard features 
for the bind operation as in DCC, they provide as many defini¬ 
tions for bind as different type of values produced by it. More¬ 
over, their implementation needs to be compiled with the flag 
-f allow-undecidable-instances, in GHC. Our work, in con¬ 
trast, defines only one bind operation for LIO, without the need for 
such compiler extensions. 

Harrison and Hook show how to implement an abstract oper¬ 
ating system called separation kernel [16]. Programs running un¬ 
der this multi-threading operating system satisfy non-interference. 
To achieve this, the authors rely on the state monad to represent 
threads, monad transformers to present parallel composition, and 
the resumption monad to achieve communication between threads. 
Non-interference is then enforced by the scheduler implementation, 
which only allow signaling threads at the same, or higher, security 
level as the thread that issued the signal. The authors use mon¬ 
ads differently from us; their goal is to construct secure kernels 
rather than provide information-flow security as a library. Our li¬ 
brary is simpler and more suitable for writing sequential programs 
in Haskell. Extending our library to include concurrency is stated 
as a future work. 

Crary et al. [8] design a monadic calculus for non-interference 
for programs with mutable state. Similar to our work, their lan¬ 
guage distinguishes between term and expressions, where terms are 
pure and expressions are (possibly) effectful computations. Their 
calculus mainly tracks information flow by statically approximat¬ 
ing the security levels of effects produced by expressions. Com¬ 
pared to their work, we only need to make approximations of the 
side-effects of a given computation when using toLabeled; the 
state of LIO keeps track of the dynamic security level upper bound 
of observed data. Overall, our dynamic approach is more flexible 
and permissive than their proposed type-system. 

Pottier and Simonet [30, 35] designed FlowCaml, a compiler to 
enforce non-interference for OCaml programs. Rather than imple¬ 
menting a compiler from scratch, and more similar to our approach, 
the seminal work by Fi and Zdancewic [25] presents an implemen¬ 
tation of information-flow security as a library, in Haskell, using a 
generalization of monads called Arrows [19]. Extending their work. 


Tsai et al. [7] further consider side-effects and concurrency. Con¬ 
tributing to library-based approaches, Russo et al. [32] eliminate 
the need for Arrows by showing an IFC library based solely on 
monads. Their library defines monadic types to track information- 
flow in pure and side-effectful computations. Compared to our dy¬ 
namic IFC library, Russo et al.’s library is slightly less permis¬ 
sive and leverages Haskell’s type-system to statically enforce non¬ 
interference. However, we note that our library has similar (though 
dynamic) functions provided by their SecIO library; similar to 
unlabel, they provide a function that maps pure labeled values 
into side-effectful computations; similar to toLabeled, they pro¬ 
vide a function that allows reading/writing secret files into compu¬ 
tations related to public data. 

Recently, Morgenstem et al. [27] encoded an authorization- 
and IFC-aware programming language in Agda. Their encoding, 
however, does not consider computations with side-effects. More 
closely related, Devriese and Piessens [12] used monad transform¬ 
ers and parametrized monads [3] to enforce non-interference, both 
dynamically and statically. However, their work focuses on modu¬ 
larity (separating IFC enforcement from underlying user API), us¬ 
ing type-class level tricks that make it difficult to understand errors 
triggered by insecurities. Moreover, compared to our work, where 
programmers write standard Haskell code, their work requires one 
to firstly encode programs as values of a specific type. 

Compared to other language-based works, FIO uses the notion 
of clearance. Bell and Fa Padula [5] formalized clearance as a 
bound on the current label of a particular users’ processes. In the 
1980s, clearance became a requirement for high-assurance secure 
systems purchased by the US Department of Defense [11]. More 
recently, HiStar [39] re-cast clearance as a bound on the label of 
any resource created by the process (where raising a process’s label 
is but one means of creating a something with a higher label). We 
adopt HiStar’s more stringent notion of clearance, which prevents 
software from copying data it cannot read and facilitates bounding 
the time during which possibly untrustworthy software can exploit 
covert channels. 

7. Conclusion 

We propose a new design point for IFC systems in which most 
values in lexical scope are protected by a single, mutable, current 
label, yet one can also encapsulate and pass around the results of 
computations with different labels. Unlike other language-based 
work, our model provides a notion of clearance that imposes an 
upper bound on the program label, thus providing a form of discre¬ 
tionary access control on portions of the code. 

We prove information flow and integrity properties of our de¬ 
sign and describe FIO, an implementation of the new model in 
Haskell. FIO, which can be implemented entirely as a library 
(based on type safety), demonstrates both the applicability and 
simplicity of the approach. Our non-interference theorem proves 
the conventional property that lower-level results do not depend on 
higher-level inputs - the label system prevents inappropriate flow 
of information. We also prove containment theorems that show 
the effect of clearance on the behavior of code. In effect, lower¬ 
ing the clearance imposes a discretionary form of access control 
by preventing subsequent code (within that scope) from accessing 
higher-level information. 

As an illustration of the benefits and expressive power of this 
system, we describe a reviewing system that uses FIO labels to 
manage integrity and confidentiality in an environment where users 
and labels are added dynamically. Although we have use FIO for 
the AChair API and even built a relatively large web-framework 
that securely integrates untrusted third-party applications, we be¬ 
lieve that changes in the constructs are likely to occur as the lan- 


guage matures. This further supports our library-based approach to 
language-based security. 

An interesting future work consists on extending our library 
to handle concurrency. Enforcement mechanisms for sequential 
programs do not generalize naturally to multithreaded programs. 
In this light, it is hardly surprising that Jif [29], the mainstream 
IFC compiler, lack support for multithreading. Due to the monadic 
structure of LIO programs, we believe it is possible to extend our 
library to consider concurrency, that addresses termination [2] and 
internal-timing leaks [38], 
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